home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
QRZ! Ham Radio 8
/
QRZ Ham Radio Callsign Database - Volume 8.iso
/
pc
/
files
/
p_misc
/
netconf.arc
/
TEXNET.003
< prev
next >
Wrap
Text File
|
1988-12-17
|
10KB
|
185 lines
[ Note: This series of articles was found on Compuserve and downloaded
from HAMNET there on 21 July 1985 by Dwight Ernest KA2CNN 70210,523. ]
An Introduction to Networks
part 3
by T.C. McDermott, N5EG
networks SIG, TPRS
The last article discussed End-to-end Vs. Hop-to-hop methods of
acknowledge, and the attendant advantages of each. As you may recall,
one of the disadvantages of the HHA was the possibility of a network
failure still allowing the sender to have been acked for data that may
not, in fact, have been received.
Generally, this is not a problem. If communications fails along a
path we naturally tend to want a re-transmission of the entire contents
of whatever file we may have been sending. If we happened to be in the
keyboard mode, then since the communications fialed, we cannot continue
to send anyway. Thridly, our TNC's do not tell us how much data they
have in their transmit buffers that has not been acknowledged, so the
HHA network really doesn't differ from the types of responses that we
are used to from the TNC - LAN system.
If we must guarantee the absolute integrity of a file transfer,
then we should implement some type of block numbering and sequencing
program that controls the file transfer process. In essence, something
like the MODEM7 protocol tacked on top of our existing TNC protocol
would guarantee the complete integrity of files transfered. We would
probably want to add onto the MODEM7 system a little bit, perhaps to
record what was and was not sucessfully transfered, and perhaps a method
of automatically re-establishing the connection to the other station,
and continuing with the transfer process until it is sucessfully
completed, and then tearing down the connection.
This additional program that we would run on each of our end-user
computers (both sender and receiver) is the LAYER 4 of the OSI model -
the transport layer. Since the network we are talking about
constructing is thus releived of absolute ACK integrity by the presence
of this additional program (in those rare instances where it is really
needed) then our netork is only restricted to providing a reasonable
guarantee of integrity, perhaps guaranteeing that packets arrive in the
correct sequence, and without bit errors. Thus with an emphasis on the
HHA VS. the EEA methods, we have decided to build a network that
optimizes throughput and response, allowing for a layer 4 program in the
event it is needed, but not sacrificing the performance of the network
for the vast majority of the uses of the network. This trade-off is
usually described as a speed-integrity tradeoff in the literature.
Now that a decision has been reached on the desired attributes of
the network, that is speed, and simplicity, we may concentrate on one
final interface aspect, and that is how the LAN (i.e. the TAPR TNC's)
are to interface and establish connection through the network. This
linkage is the peer communication between two layer 3 processes that is
described by Tannenbaum [1].
In the 7-layer OSI model, subnet communication (that is
communication through a network) is established between two layer 3
processes - that is, the TAPR TNC AX.25 mode, and the network entrance
and exit layers. Although AX.25 is sometimes discussed as a layer 2
protocol, in the LAN application it is really a layer 3 process. It
establishes, communicates, and terminates, and thus it is a layer 3
process. Similarly the network, upon command, will establish,
communicate, and terminate, thus it also is performing a layer 3
function.
Why the concern about which layers to call each other? Because it
is desirable that the TNC's be able to use the network without any
modification. Thus the network must be compatible to the way that the
TNC establishes, maintains, and terminates connections, since the
network must establish, maintain, and terminate connections to or from
TNC's and itself. We are faced with the choices as to how the TNC and
the network can talk with one another.
One method of network interface is to assume that the network is
transparent, that is it looks like a digipeater. Then you would use
your TNC as though the network were a single digipeater (even though it
might have many hops, it would appear to the TNC as one digipeater).
Another method is to treat the network as a spearate LAN address.
This is, you would connect to the network. Then the network would
engage in an interactive session with you regarding the type of service
that you needed, that is, who you wanted to talk to, and how to get
through the network to that place. Once the network computer was
satisfied, it would then engage in comunications between the endpoints.
Your TNC would think it was connected to the network, not to your actual
destination station.
Each of these connection methods has advantages and disadvantages.
We will discuss some of them here.
The digipeater-emulation method is a very natural method to use,
because the connection method is familiar to all of the TNC users. Let
us establish the following scenario: WD0ETZ in Carrollton wishes to
communicate with WD5GAZ in Houston. WD0ETZ knows that this distance
will require the use of the network. So WD0ETZ proceeds as follows...
Connect WD5GAZ VIA DALLAS
This seems simple enough, but some interesting problems crop up
almost immediately. How does the network know where to find WD5GAZ?
What path is required to get there? WD0ETZ's TNC is going to want to
see ACK's from WD5GAZ, not from DALLAS.
First problems first. One way for the network to know how to find
WD5GAZ is for it to keep tables in all of the sites of each and every
network user. This is really not practical in an amateur environment
because hams move, come, and go, and even change callsigns, and with
very many users, it takes a lot of manual intervention to keep the
tables current. It also takes a lot of computer power in the network to
store and route messages based upon these tables. In the event of a
network crash, the tables would have to be reloaded, etc. A simpler way
would be for the originator, in this case WD0ETZ, to specify the network
"hop-off" point, that is, the location in the network where WD5GAZ is
likely to be found. For example:
Connect WD5GAZ VIA DALLAS,HOUSTON
Now the network knows that the entry point is this network (which
is "DALLAS", the one hearing WD0ETZ) and the exit point is HOUSTON.
Perhaps different types of names would be chosen for network nodes.
Grid-squares and major city names seem to be two obvious choices. What
about the route to take to get along the network? There is an
incomplete but simple answer to this question - make a linear network
(or a simple variant of linear). A linear network is one where the
network is basically a straight line. Thus there is by definition only
one path between any two points. A few other questions. What if WD5GAZ
is not within range of the HOUSTON node, but perhaps within range of a
station that is near to the node - for example suppose that WA5AAA is
between the HOUSTON node and WD5GAZ. Then...
Connect WD5GAZ VIA DALLAS,HOUSTON,WA5AAA
What if WD0ETZ is not within range of the DALLAS node, but is
within range of WB5QNG, who is within range of DALLAS ?
Connect WD5GAZ VIA WB5QNG,DALLAS,HOUSTON,WA5AAA
Well, the addressing would work. But the network entry point has
to do some strange things to the address field. Remember in the HHA
scheme it would be the address DALLAS that is actually ACKing WD0ETZ,
and not WD5GAZ that would be ACKing WD0ETZ, so the network node has to
play "fast-and-loose" with the address headers in the digipeat field.
The other method is fairly straight forward. The user connects to
the network, and then enters an interactive Q & A session:
Connect DALLAS
Welcome to TEXNET - DALLAS node.
There are currently 4 other users connected to DALLAS.
Enter destination callsign ? ( WD5GAZ would be entered here)
Enter network exit node ? ( HOUSTON would be entered)
Enter destination digipeaters ? (WA5AAA would be entered)
CONNECTION ESTABLISHED - PROCEED
Notice one thing in the above scenario: more than one station may
be connected to the network node entry and exit points. This is
something that is a little foreign to the AX.25 protocol, that is
MULTIPLE VIRTUAL CHANNELS to a single TNC. In this case it is still
compatible with AX.25 since both source and destinations callsigns are
part of the AX.25 standard. Only the network nodes have to have this
special property of having to be connected to several different stations
simultaneously - thus the AX.25 code for these controllers is a little
different from a normal implementation. But only the network requires
these special TNC's (actually they are built into the node controller,
and aren't identifable as a separate device).
The reason that the network should allow for multiple virtual
channels is to allow multiple people to simultaneously use the network.
Since we will put high-speed radios in the network between nodes, we
should take advantage of the bandwidth available.
At this point we will not go into the network protocol required to
implement these connection schemes, that "play-games" with the address
header fields to keep our TNC's happy, and that perform the HHA transfer
between the network nodes, do flow control inside the network, and route
the signal to the destination. That is the subject of another article.
The next article will deal with the type of hardware that will be
required to support this concept of a network, and it turns out to be
surprisingly modest. There are some other concerns about capacity,
response time, channel utilization, reliability, and remote network
"resuscitation" (in the event of software failure) that will also be
addressed in part 4 of this series.